This entry was adapted from some comments I wrote for a different, mostly orthogonal, journal post. I hope it's not too flamebait. If you have something to say, please try to be civil and good-natured. Here goes nothing:
Most modules on CPAN carry a licensing blurb saying something like "you can distribute this software under the same terms as Perl itself". This obviously begs the question what does it mean. Here is what it means for different Perl versions:
Early versions of perl, before it adopted the GPL were under a very restrictive loosely-defined licence.
After a while perl adopted the GPL exclusively.
Eventually, seeing that some people and companies had problems with the GPL, Larry Wall phrased the so-called "Artistic License", which was supposed to be more permissive than the GPL, but purposely phrased vaguley, and as such was found to be non-free and ergo GPL-incompatible.
In any case, the perl implementation was dual-licensed under the "Artistic License" (version unspecified) and the GPL version 2 or any later version. perl5 is still licensed under these terms.
For Parrot and for future work on Perl 6, the Artistic License 2.0 was created based on the original Artistic License. This license has been approved as a free software licence by the Free Software Foundation and found to be compatible with the GPL version 2 or Later. Parrot now carries this licence.
There's also the Clarified Artistic License which is an earlier effort to correct the original Artistic License and is the minimal set of changes to make it FSF-free and GPL-compatible. I suppose that now the Artistic License 2.0 would be preferable.
The problem is that perl up to and including perl-5.10.0 and bleadperl (which were licensed under the GPL version 2 or above but only the "Artistic License" not the "Artistic License version 1.0 or above". I've already noted that the Artistic License is problematic, but the GPL has its own share of potential problems (see also its FAQ), and is otherwise widely mis-understood, over-hyped (both positively and negatively) and disputed. For example, unlike the Artistic License, it does not allow (at least by linking or normal function calls) non-GPL-compatible code, including all non-open-source code, to make use of it.
Now, since both the "GPL version 2 or above" and the original "Artistic License" are problematic, and the term "under the same terms as Perl" may probably mean just that if it's a perl5 module (although who knows what it would means if someone would ever write a compatible Perl 5 implementation under a different software licence), then licensing a module as such is probably no longer such a good idea. There are several alternatives:
So my suggestion is that you use one of these licensing phrasings for your future work, and to re-license your old CPAN or Perl work (copyright ownership permitting) under such phrasings. It remains to be seen what will happen with perl5 itself which has 905 authors as of perl-5.10.0 many bringing in their own ownerships of the code. The Linux kernel now faces a similar problem if it would wish to adopt a different licence than the GPL version 2 (and no later version).
I suppose you can still make most use of perl5-like licensed code, in your own open-source, proprietary or in-house code, without getting sued, so I wouldn't worry too much. But it would still be a good idea to convert newer code (and code that can be easily converted) to licensing terms that are less ambigious, more usable, and that would play better with future versions of Perl.
For the record, most of my Perl and non-Perl open-source code is either Public Domain or MIT X11-licensed (which are both extremely permissive and allow sub-licensing), or if it is derived from a different code, then under the same licensing terms, but while disclaiming my explicit or implicit ownership (to allow the originator to relicense future versions of the code). The latter policy applies to my (relatively limited) contributions to perl5 where I am listed in the AUTHORS file.
Re:Linux kernel really doesn't have the problem...
Shlomi Fish on 2008-04-04T08:45:10
Last I heard Linus said no to GPL3 and the kernel.Well, my exact phrasing was "The Linux kernel now faces a similar problem if it would wish to adopt a different licence than the GPL version 2 (and no later version)." What I meant was that if at any given time, they would prefer to use a different licence, not necessarily the GPLv3, they would need to ask permission from all the copyright holders, or re-write their code.
I know of several projects that have changed licensing this way: Mozilla which converted from the MPL to a triple MPL/LGPL/GPL licensing, and SpamAssassin that converted from GPL+Artistic to the Apache licence.
Of course, with the MIT X11 licence or a similar one, converting the code or forking/spinning-off under a different license can be done without requesting the copyright holder. Whether this fact is desirable is a matter of taste.
Remains to be seen what happens. Good points.Yes.
Re:Linux kernel really doesn't have the problem...
Aristotle on 2008-04-05T18:50:27
Note that the figure of 905 authors probably does not derive from a full blame analysis, in which case it is quite likely that no code remains from a number of minor contributors, which would make the task somewhat less monumental than that number might suggest.
Re:Linux kernel really doesn't have the problem...
Shlomi Fish on 2008-04-09T19:22:22
Well, a linewise "blame"/"annotate" feature is not an accurate way to determine ownership. For example, let's say I added a huge patch to the perldoc pods adding several sections, and lots of text. My patch as applied.
Afterwards, someone noticed that all my lines had trailing whitespace, and submitted a patch to remove them. This patch was submitted, and all of my added lines are now marked as his changed lines. As a result, the line-wise blame command will claim I'm not a contributor, while in fact I am.
This example illustrates that blame can have false negatives and false positives. Plus, if I wrote some subtantial code, and someone modified it (without rewriting it from scratch), then I'm still entitled to copyright of the code.
Re:Linux kernel really doesn't have the problem...
Aristotle on 2008-04-09T20:07:13
You are arguing about specific trees, whereas I am talking about the forest: that it is quite likely that the number of contributors who can actually claim copyright today is probably not quite as high as a thousand people.
Re:Why is this a problem?
stu42j on 2008-04-04T19:50:38
I think the problem is the ambiguity. Do you mean any version of Perl? The latest version? And what exactly to you mean by "Perl" anyway?
Perhaps it is intentionally ambiguous, though. I imagine that most people who use the same as Perl terms are simply not that concerned about how their code is used. Even still, I think it would be nice if there were a URL you could point to and say "there, that is what I mean". Something like: http://www.cpan.org/src/LICENSE
The GPL has held up in every single court case against violators in the US and Germany. (I don’t know what the situation is like in other countries. It may differ there.)
(In most every case, the defendant demurs and settles before the case is actually tried before court. That’s probably not because they’re afraid that the GPL may be deemed invalid.)
Re:Disputed?
Shlomi Fish on 2008-04-05T19:57:40
By disputed I didn't mean "legally" disputed, and being a non-native English speaker I may have misunderstood it. By disputed I meant that it is:
- Controversial.
- Not fully understood by many FOSS activists, including not by many people who've licensed their code under it.
- That some people dislike it, thinks it complicates matters too much, or think it's not needed to protect free software from abuse.
A certain Israeli BSD developer noted that sites like gpl-violations.org are "the anti-thesis of hacking" and he's still waiting for a bsd-violations.org site. What he meant that programmers should just focus on writing good code, and making sure their software is widely used and supported, rather than pursuing people who supposedly violate it.
Another thing he noted (and I concluded too) is that you cannot really "close the source" of a BSD-style-licensed program, only fork a version under a different licence. And I heard of at least one case, where a GPLed software was spun-off into a proprietary product by the copyright holders and left the old GPLed code unmaintained and practically useless now.
I'm not sure the GPL is worth the extra aggravation and people may disagree with me or may licence their software differently, and that's OK I don't go as far as claiming the GPL is not free-as-in-speech, or whatever, like some BSD advocates do (and then confusingly say that restricted sourceware, like what qmail used to be or Microsoft's MFC is, is still open-source). But the last thing I need to worry about as a developer, an end-user and an advocate of FOSS is how the software can be misused or what can be done to stop this "misuse". The less people bother me with legalities the better, because I have enough other aspects of software quality and popularity to worry about.
Re:Disputed?
Aristotle on 2008-04-06T06:46:17
Right, then “disputed” was the wrong word. “Controversial” would have been a much better choice.
programmers should just focus on writing good code, and making sure their software is widely used and supported, rather than pursuing people who supposedly violate it.
See, that’s an excellent demonstration of your point that nobody really understands licences. (By the same token I cannot in good consciousness claim that I understand them; the most I can say is that I have identified more errors in my reasoning than many non-lawyer type people.)
The core thing to understand with licences is that the licence never affects the copyright holder. The copyright holder themself can do whatever they damn well please. What the licence regulates is who has what rights when the work has been distributed by one third party to another.
In this exchange, the GPL favours the recipient. The MITL favours the distributor.
That’s it. Neither licence is more or less free; both give one party power over the other, they just differ in which party gets the preferential treatment.
Also, to come back to this point:
programmers should just focus on writing good code
This combines at least two fallacious ideas. One of them is that all the skill necessary to drive a software project to success is programming aptitude. (Not true; thus, the fact that some project devotes effort to track down GPL violators does not at all imply diminished effort in programming.) Another is that time is fungible, ie. time you spend watching TV, say, is interchangeable with time you spend programming. (Not true; just because a programmer devoted some of his time doing something other than programming doesn’t mean he could equally well have been coding in the same time.)
The fact that bsd-violations.org does not exist may possibly imply that BSD people care more about getting good code into widespread use, but it certainly does imply that by the very nature of their licence they care less about the power of the recipient of their software – to a first approximation, anyway. It can be argued whether this ultimately ends up benefiting said recipient more, or not.
But in any case, as far as I can see, it really is not possible to declare either licence the better one. There is a fundamental polarity that cannot be resolved, and the two philosophies, BSD vs FSF, merely fall on either side of it. (This is why I currently like the LGPL best; it attempts to straddle the divide.)
Re:Disputed?
Shlomi Fish on 2008-04-06T13:46:30
Right, then “disputed” was the wrong word. “Controversial” would have been a much better choice.
Fair enough. "Controversial" it is. I'm pretty sure I heard "disputed" used for non-legal things, but in this context it might be misleading.
programmers should just focus on writing good code, and making sure their software is widely used and supported, rather than pursuing people who supposedly violate it.
See, that’s an excellent demonstration of your point that nobody really understands licences. (By the same token I cannot in good consciousness claim that I understand them; the most I can say is that I have identified more errors in my reasoning than many non-lawyer type people.)
Well, I read the MIT Licence and understood everything there. Then I realised sub-license means something a bit different than what I thought. I also read the SleepyCat (now part of Oracle) BerkeleyDB licence and it was pretty obvious and easy to understand. It is a GPL-like licence, but from what I understood somewhat more liberal in allowing even non-GPL-compatible, and proprietary source to link against it.
I read the GPLv2 one day and didn't understand most of it. My (superficial I am sure) understanding of the GPLv2 is by reading what educated people said about it and judging for myself what sounds more logical.
Again, like I wanted to say, some licences can be interpreted in several different ways by the Law. But one doesn't have to be a lawyer specialising in copyright law to be able to have a more superficial understanding of what a licence entails. It helps though.
The core thing to understand with licences is that the licence never affects the copyright holder. The copyright holder themself can do whatever they damn well please. What the licence regulates is who has what rights when the work has been distributed by one third party to another.
In this exchange, the GPL favours the recipient. The MITL favours the distributor.
Not sure I agree with it. Sometimes people can play different roles.
That’s it. Neither licence is more or less free; both give one party power over the other, they just differ in which party gets the preferential treatment.
Also, to come back to this point:
programmers should just focus on writing good code
This combines at least two fallacious ideas. One of them is that all the skill necessary to drive a software project to success is programming aptitude. (Not true; thus, the fact that some project devotes effort to track down GPL violators does not at all imply diminished effort in programming.) Another is that time is fungible, ie. time you spend watching TV, say, is interchangeable with time you spend programming. (Not true; just because a programmer devoted some of his time doing something other than programming doesn’t mean he could equally well have been coding in the same time.)
I see how you can deduce that I meant that from what I said, and I therefore apologise. However, I'm well aware of both of these fallacies and that wasn't my intention. What I meant to say was something along the lines of Linus Torvalds' "Show me the Code!". I.e: do whatever you can do to best promote your software and make it of better value to the users, popular, etc. In my opinion, going after violators of the licence legally is an obstacle to this. That's because legal processes are time-consuming, money-consuming, repute-destroying, and leave a bad taste in your mouth (to say nothing of the fact that people and organisations may be too quick to sue). Even if you win, you probably have lost a friend, a customer, your reputation, etc. Don't go there unless you have to.
I believe (and you can disagree with me) that by using BSD/PD-like licences for my software, I am best making sure that I have the fewest worries about how my software is going to be abused, because I promise myself that there's very little chance of it to be abused. And this makes me happier, keeps me out of as much legal trouble as possible (whoever initiated it), and gives me much more time to do other things. If Microsoft or SCO or Satan himself wants to use my code in his "proprietary" product, or modify it to suit his needs, that's fine by me. That's because it's also fine if Debian, Red Hat, NASA or my best friend will do it.
What I want to say is that sometimes spending time on something does not come at the exchange of something else. This is one reason why a common argument that says that porting software to Windows is bad because it wastes time is wrong. But legal hassles are a nice way to waste and accumulate many resources that are wrong.
I can respect companies and people who distribute GPLed products with an optional commercial exemptions (e.g: SleepyCat BerkeleyDB, TrollTech's Qt, etc.). However, if I were them I wouldn't waste too much time trying to hunt them because they probably wouldn't have become paying customers anyway.
The fact that bsd-violations.org does not exist may possibly imply that BSD people care more about getting good code into widespread use, but it certainly does imply that by the very nature of their licence they care less about the power of the recipient of their software – to a first approximation, anyway. It can be argued whether this ultimately ends up benefiting said recipient more, or not.
It probably should better be bsdl-violations.org for BSD Licence. I hate grouping the BSD people together with their licence and with calling their anti-thesis the GNU/Linux/GPL camp. The BSD developer I paraphrased kept making this mistake, and I don't want to repeat it. But back to our subject.
You are right that it may not be indicative of whether it benefits or harms them. The How to become a Hacker howto, can be interpreted to mean that both the GPL is better and the BSD or the LGPL are better. ESR later voiced an opinion against continuing to use the GPL, saying it was no longer necessary, and basically too much trouble. At Raymond's defense I should say that he still didn't try to spread misleading information about the GPL.
But in any case, as far as I can see, it really is not possible to declare either licence the better one. There is a fundamental polarity that cannot be resolved, and the two philosophies, BSD vs FSF, merely fall on either side of it. (This is why I currently like the LGPL best; it attempts to straddle the divide.)
The LGPL is not too bad a licence. You're probably safer with LGPLv2 and above, because the LGPLv3 is not GPLv2 compatible. (%-)). I think it makes sense for Perl modules too, if you don't intend the module to be integrated into the perl5 core. I was told the Artistic licence (or at least the Artistic 2.0) makes even more sense for Perl, but thinking about it makes my head spin.
In any case, I am a firm believer in free choice and a "Do and Let Do" attitude. If you want to publish your own silly Ozy and Millie comics fetcher under the Microsoft Vista EULA then all the power to you. I'll stay a clear mile away from this script, but someone may find it useful.
I don't think developing or distributing proprietary software is immoral or unethical or whatever like the FSF thinks. Since the BitKeeper saga, where I got personally burnt, I've become more suspicious of most classic non-free software, but I'm still using it as long as I try not to depend on it. (Adobe Flash being a notable exception). But I still see myself as a developer and advocate of free software because there are enough other ways I can make money from my software (assuming I want to) besides restricting its licence by one iota more than the MIT X11 Licence. That is assuming I actually do, which I don't see as a necessity.
The public domain is mainly a feature of US legislation. Similar costructs exist in other jurisdictions, but not everywhere. F.ex., in Germany, you can say you’re putting your work in the public domain all you want but it won’t be legally binding in court.
Germany, f.ex., has “author’s right,” not “copyright,” and an author can’t renounce their authorship of their work. The only way for their rights to expire is when they die. However, you can grant usage rights, eg. by way of a licence.
So instead of putting your code in the public domain, release it under a licence that grants sufficient rights for your liking. Probably this will be the MIT licence for most people who are considering the public domain.
Re:Do not put your code in the public domain
Shlomi Fish on 2008-04-05T19:30:58
I am not a lawyer or a legal expert, but I too heard that the Public Domain is a problematic concept, especially when it comes to software. There's some widely used software out there that's Public Domain and it seems to be doing pretty fine. (Though in one of the latest FLOSS weekly interviews, the SQLite creator and maintainer said he has been providing a for-pay token commercial licence to SQLite to please the lawyers of some companies which have a problem with it.). Nevertheless, you are right that the MIT licence is now preferable.
I've started using PD for my original software, and later on converted to using the MITL for new software (without converting my old software to it). One of my PD software has been integrated by a German FOSS developer into a GPLed KDE program (kpat) and he didn't have a problem with the licensing.
One advantage that the Public Domain has is the fact that it is easier to understand even if you don't have a lot of software licenses knowledge, which has become a necessary mental burden for me and most other people as of late. But I guess it's too minor to be worth the extra complications.
Re:Do not put your code in the public domain
Aristotle on 2008-04-05T19:50:05
Yeah, well, individual developers and the small fish companies tend not to care much (as well they don’t tend to care much about licensing in general). For companies large enough to have a legal department, though, it tends to be a worry.
And yeah, it would be nice if there was a good licence even simpler than the MIT licence. (I’ve expressed this desire before.) My personal preference is LGPL for applications and large libraries and some hypothetical licence even less restrictive than MITL for anything relatively small.
Re:Do not put your code in the public domain
Shlomi Fish on 2008-04-09T19:30:25
I never realised the X11L was not free enough. I thought the WTFPL was a nice joke, but I see that it may make some sense. It's too bad the concept of Public Domain is so much legally disputed, especially when it comes to software.
Well, I'm still going to use the X11L for what I do, as there isn't a better alternative, and people can interpret it to mean that I basically don't care what you do with it. (As long as one doesn't do terminal PD-violating-things like suing me for copyrights violations that I wrote and made X11L.)
Re:Do not put your code in the public domain
jhi on 2008-04-11T01:18:37
: It's too bad the concept of Public Domain is so much legally disputed,
It is not "disputed". The whole concept Public Domain *does* *not* *exist* outside U.S. legal system. Proposing it or even talking about it is like arguing for, say, U. S. electoral college (if you don't know, you don't want to know) for other countries. Makes no sense whatsoever.
And in general, I find software people talking about licenses and other legal matters about as funny as lawyers talking about programming.
Re:Do not put your code in the public domain
Shlomi Fish on 2008-04-11T07:33:37
It is not "disputed". The whole concept Public Domain *does* *not* *exist* outside U.S. legal system.Are you sure? According to this wikipedia article about the Public Domain, it exists in several other countries besides the U.S. (though the article in question may be wrong). I know many countries (including Israel) have a limited term of copyrights, after which something hapens to the work. Normally, I believed it enters the Public Domain (or "Nahh'lath Haklal" in Hebrew), but I could be wrong.
And in general, I find software people talking about licenses and other legal matters about as funny as lawyers talking about programming.I hope you're not proposing that we must not discuss it. Software Licences affect us all, and abusing them or not understanding may result in bad stuff happening to us, or in our software not being useful. In Israel there is an idiom that any citizen must be aware of the law, and may read the Law Canon in public libraries (and possibly now in the Internet) and they are expected to know it all and not violate any of it.
Likewise, I don't restrict discussion about programming to people who are expert programmers. You can never be good enough as a programmer, but still often less experienced programmers are more clueful in certain respects than programmers with many years of experience.
You should be aware that over-specialisation is very bad. Researches by Biologists and Anthropologists have shown that many of the species and cultures that became extinct did so due to over-specialisation.
I'm not claiming I'm qualified to represent someone in court, or to do other legal work that requires a lawyer, but I'm still qualified to discuss such legal matters that, like it or not, affect all of us.
Module authors should license their code “under the same terms as Perl $VERSION” rather than the common default of “under the same terms as Perl”. Note the presence of a specific version. This addresses the ambiguity problem.
Licensing the code differently offers no benefit and should be discouraged, even though other licences may be better than the dual licence along various axes.
Why?
Because the licence of Perl itself is not going to change any time soon, and any user who uses Perl code will need to use Perl itself. Any user who is using Perl code therefore has already had to accept the dual licence, which makes it a known quantity. In contrast, if a module is licensed differently, the user will have to evaluate that licence separately. For corporate users this may be a lengthy process involving legal departments, which may stop them from considering your module at all. If you are not a legal expert you may also unwittingly pick a licence that is subtly incompatible with the Perl licence or the licence of some other module which is similarly individualistically licensed, creating problems for anyone who may need to combine them.
Going with established licensing terms is in the best interests of the CPAN as a while.
Re:What module authors SHOULD do
Aristotle on 2008-04-05T21:12:06
… err, as a whole.
Re:What module authors SHOULD do
Shlomi Fish on 2008-04-06T05:09:04
Hi Aristotle!
Interesting point, but I still disagree. I think you're making here a fallacy, which is of more general nature, but I'll focus on our example. First of all, sometimes Perl code can prove useful without the perl implementation itself. Often it can be converted to python, Ruby, C, Java or a different language directly, often by copying and pasting code and then modifying it. To say nothing of automated Perl-to-Perl6/python/etc. converters like the one Larry Wall started writing. (He has already implemented a way to dump the syntactic structure of perl5 code into XML/YAML.)
But even if that's not the case and the code will remain Perl and run with perl5, then there is a difference. Let's take my LM-Solve (a solver for some puzzle games, commonly known as Logic Mazes, that are easy to solve with a computer), which is written in Perl and licensed under the MIT X11. Now let's suppose Microsoft takes my LM-Solve, forks it, adapts it to solve all Solitaire card games, Sudoku, Nurikabe, and Kakuro, adds a GUI, makes it 1,000 times faster, all while keeping it written in Perl 5 and running under perl 5. Then they release it as a commercial, proprietary product called Microsoft Logic Mazes Solver Enterprise Edition XP
.NET Pro. They still respect the licence of perl 5 and distribute all the source code on their package. However, the LM-Solver-derived code and a lot of code that was added is now no longer free. That's OK by me, because I've given them permission to do so by licensing LM-Solve under the MIT X11 licence. An attribution somewhere would be nice of course, but not absolutely necessary. (They do give credit to Eric S. Raymond among others).
So now if I wish to catch with the Microsoft product, I'll need to implement this functionality myself. Again, it's OK. However, if I licensed it as same terms as perl 5, then from my understanding, I still could use all of my original code.
It sometimes makes sense to make something more permissive (or more restrictive) than the implementation's licence. You wouldn't expect an open-source
.NET software to carry the Microsoft .NET EULA, do you? (And there are plenty of FOSS .NET software, and some of it still has problems running on Mono). And if you write a Perl program that uses Oracle and runs on Apache's mod_perl, which licence do you use? ;-) Many (all?) of the "BBC" modules on CPAN are released under the GPL exclusively. I don't think you can get a commercial licence for these modules from the BBC, though you may be able to get an exemption from the GPL in certain cases. Again, we can assume they didn't like the Artistic licence enough and preferred the GPL exclusively. Don't like it - re-implement it or try to convince them to use a more permissive licence.
So it's not that simple as just saying that it should be under the same terms as perl-5.10.0 or whatever. You can often find code modules under different GPL compatible licences in GNU or otherwise GPLed software, and it was not converted to the GPL. That's because the software as a whole is GPLed, and it doesn't matter that an isolated part is not.
Re:What module authors SHOULD do
Aristotle on 2008-04-06T06:13:43
OK, but… what is your point? You tried to give an example… I think it kinda fizzled out at the end? I cannot make a coherent argument for anything in particular from what you are saying.
My point is pretty simple: that users in companies with legal departments are likely to have a list of approved licences for free software, and that using software provided under a licence that is not on that list will require a lengthy process of evaluation, and that in such a company, if Perl is in use, then the dual licence is necessarily already on the list of approved licences. So any module deviating from the Perl dual licence will be disadvantaged because developers looking for code to solve some problem are likely to take some other module or even just roll their own before they go through the bureaucracy of getting a new licence approved.
So far this is all but fact, not opinion, and therefore not subject to dis-/agreement.
You may dispute the import of this situation, saying that it is too rare among all the users of your code to care about. Maybe you want to claim that the MIT licence is widespread enough that it will be part of any list of approved licences sooner or later.
But it’s fact that by licensing code under terms other than those of Perl, you create a real potential to inconvenience some users.
The question is, does licensing code under terms other than Perl’s offer any tangible benefits? So far, the thrust in that direction seems to be philosophically argued – as in the debate over the necessity of copyleft, say. (I think this is what you were trying to make a case about in your muddled response, but I could not extract the argument proper from it.) And the pragmatist in me finds that unsatisfactory.
After all, we are all hackers and none of us likes to deal with licences (though some less so than others). I see the value in standardising on a choice, even if it’s merely a suboptimal compromise, purely for the benefit of minimising the amount of licensing related minutiæ that a user will have to deal with.
Re:What module authors SHOULD do
Shlomi Fish on 2008-05-08T13:50:19
Hi Aristotle!
Sorry for the late response.
OK, but… what is your point? You tried to give an example… I think it kinda fizzled out at the end? I cannot make a coherent argument for anything in particular from what you are saying.
What I meant to say was that they can take my code, modify it and sublicence it under a different (possibly proprietary licence). Against, most programs on Linux use the LGPLed glibc, which does not allow that, but as a whole proprietary code on Linux is possible. And you can sublicence X-Windows, XLib, or different BSD licences.
My point is pretty simple: that users in companies with legal departments are likely to have a list of approved licences for free software, and that using software provided under a licence that is not on that list will require a lengthy process of evaluation, and that in such a company, if Perl is in use, then the dual licence is necessarily already on the list of approved licences. So any module deviating from the Perl dual licence will be disadvantaged because developers looking for code to solve some problem are likely to take some other module or even just roll their own before they go through the bureaucracy of getting a new licence approved.
So far this is all but fact, not opinion, and therefore not subject to dis-/agreement.
You may dispute the import of this situation, saying that it is too rare among all the users of your code to care about. Maybe you want to claim that the MIT licence is widespread enough that it will be part of any list of approved licences sooner or later.
But it’s fact that by licensing code under terms other than those of Perl, you create a real potential to inconvenience some users.
I see. Well, first of all let me say that I am not against big business. (I'm not pro-it either). However, I believe that stupidy and irrationality are the root of all unnecessary Evil, and have caused untold damage in history (much more than refraining from using my code), and I have very little tolerance for them.
If a large company's legal department is too stupid to include MIT X11 code in what they do, then they deserve the inability to use it. That's part of the reason why small companies which are much more agile and have less irrational procedures, out-compete large companies with apparently much more resources, but much more red-tape.
I'll be glad if anyone, large or small will use my code in any way they desire. But if you're stupid, you're going to pay for it much more than not being able to use my code, or the X-Windows' code (also MIT X11), or any other program. If you want me to make a version available under a different licence, contact me and I'll gladly do that, but you can do it yourself without asking me.
I can always make the code available under at an option of the MIT X11 licence, the perl 5 and the Parrot licences. But the MIT X11 licence already allows conversion to any other licence, so it seems kinda pointless.
[ Rest of message snipped. ]
Re:What module authors SHOULD do
Shlomi Fish on 2008-05-08T14:00:19
Replying to myself, I'd like to note that often small companies are also stupid in many respects, which is part of the reason why most Startups fail. But it's probably true, that so far the more a company grew, the more procedures it acquired, and the less agile it has become. As opposed to Paul Graham, I do not rule out the possibility of a large but agile and efficient company, but I'm not sure if it has happened yet.
If the you prefer the Perl[1234] license and the module works with Perl[1234], knock yourself out. But unless I'm using Perl 1, the Perl 1 license doesn't apply - I never used Perl[123] so I've never accepted their licenses. Haven't used Perl4 at current $DayJob so that doesn't touch *me* there, and we've I think stamped out all legacy SybPerl so we're done with that. (Did have a bit o' Perl4 for the $StartUp so there may be some modules I've dual-used on the old NT laptop with both Perl4 and Perl5.x licenses.)
The ambiguity is similar to the FSF recommended "or any later version" wording (but without the GPLv3 sneaking new varieties of IP into a copyright license).
Re:Obviously ...
chromatic on 2008-04-19T01:14:19
It may not be so obvious to a lawyer but quite obviously "same terms as Perl" means the same terms as already accepted by using the version of Perl you're using the module with.Perhaps from the practical standpoint this is true -- why would I distribute software that you can't actually use? -- but there's at least one court case active right now where one side is arguing in all seriousness that distributing software under the Artistic License means that you're not interested in protecting your copyright. "Obvious" has very little place in the law, sadly.
